Automatic deployment and update of hybrid applications

ABSTRACT

Described herein is a framework for deploying and updating applications (Apps). In accordance with one aspect, a source code of a hybrid application may be provided by a development environment running on a cloud server, in response to a user event. A deployment generator running on the cloud server may be automatically invoked to receive the source code of the hybrid application. The source code of the hybrid application may be further packaged to form a hybrid application package for deployment by the deployment generator. The hybrid application package may be deployed to a deployment service on the cloud server.

TECHNICAL FIELD

The present disclosure relates generally to a framework for deployingand updating applications (Apps).

BACKGROUND

Apps are developed for a wide variety of purposes. There are differenttypes of Apps. For example, native Apps are downloaded, installed andrun on devices. A native App is written for a specific kind of device orplatform. Native Apps take advantage of the various functions availableon a device. On the other hand, Web Apps reside on a server. A deviceaccesses a Web App through its browser. By being browser-based, anydevice with a browser can access Web Apps. In other words, Web Apps arenot platform or device type-specific. However, Web Apps cannot cross theboundaries of web browsers, thus restricting access to somesystem-specific resources.

A hybrid App is another type of App. Hybrid Apps combine elements ofboth native and Web Apps. Hybrid apps provide benefits of both nativeand Web Apps. For example, hybrid Apps can be accessed through a browserwhile having access to various functions and features of a device.However, deployment of hybrid Apps requires significant efforts andtime. For example, properly setting up the native developmentenvironment and preparing the required web contents is very complex andprone to errors. Updating of a hybrid App also requires significanteffort. For example, when a hybrid App is updated, the correspondingnative development environment is also required to be upgraded andupdated accordingly.

From the foregoing discussion, it is desirable to provide an approach toautomatically deploy and update hybrid Apps without complicatedenvironment setting.

SUMMARY

A framework for deploying and updating applications (Apps) is describedherein. In accordance with one aspect, a source code of a hybridapplication may be provided by a development environment running on acloud server, in response to a user event. A deployment generatorrunning on the cloud server may be automatically invoked to receive thesource code of the hybrid application. The source code of the hybridapplication may be further packaged to form a hybrid application packagefor deployment by the deployment generator. The hybrid applicationpackage may be deployed to a deployment service on the cloud server.

In accordance with another aspect, a source code of a hybrid applicationmay be provided by a development environment running on a cloud server,in response to a user event. A deployment generator running on the cloudserver may be automatically invoked to receive the source code of thehybrid application. The deployment generator may scan the source code ofthe hybrid application to identify and remove design time files,resulting in a scanned application file. The scanned application filemay be analyzed to resolve runtime dependencies of the hybridapplication as well as retrieving dependent libraries, resulting in aresolved application file. The resolved application file may be furtherconverted to files and folders compatible for deployment to thedeployment service on the cloud, resulting in a converted applicationfile, which may be compressed to form a compressed application file. Thedeployment generator may further generate a deployment metadata file,and package the compressed application file and deployment metadata fileto produce an application package. The application package may then bedeployed to a deployment service on the cloud server.

In accordance with yet another aspect, an application development systemis described. The application development system includes an applicationdeveloper running on a cloud server. The application developer furtherincludes a development environment and a deployment generator. Thedevelopment environment enables a developer to create a new hybridapplication or update an existing hybrid application to produce anupdate hybrid application, while the deployment generator packages thenew hybrid application or packages the update hybrid application, anddeploys the new hybrid application or the update hybrid application to adeployment service on the cloud.

With these and other advantages and features that will becomehereinafter apparent, further information may be obtained by referenceto the following detailed description and appended claims, and to thefigures attached hereto.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments are illustrated in the accompanying figures. Likereference numerals in the figures designate like parts.

FIG. 1 shows an implementation of an environment;

FIG. 2 shows an implementation of an enhanced App developer;

FIG. 3 shows an exemplary implementation of a deployment configurationdialog;

FIG. 4 shows an exemplary implementation of a project wizard;

FIG. 5 shows an exemplary implementation of a Source Control interface;

FIG. 6 shows an implementation of a simplified deployment process for anew App; and

FIG. 7 shows an implementation of a simplified deployment process for anupdated App.

DETAILED DESCRIPTION

In the following description, for purposes of explanation, specificnumbers, materials and configurations are set forth in order to providea thorough understanding of the present frameworks and methods and inorder to meet statutory written description, enablement, and best-moderequirements. However, it will be apparent to one skilled in the artthat the present frameworks and methods may be practiced without thespecific exemplary details. In other instances, well-known features areomitted or simplified to clarify the description of the exemplaryimplementations of present frameworks and methods, and to thereby betterexplain the present frameworks and methods. Furthermore, for ease ofunderstanding, certain method steps are delineated as separate steps;however, these separately delineated steps should not be construed asnecessarily order dependent or being separate in their performance.

FIG. 1 shows a simplified diagram of an exemplary environment orarchitecture 100. Environment 100 may have a distributed architecture.In one implementation, the environment is a cloud computing environmentwhich includes a cloud 110. The cloud, for example, is a server. Theserver may include one or more computers. A computer includes a memoryand a processor. Various types of computers may be employed for theserver. For example, the computer may be a mainframe, a workstation, aswell as other types of processing devices. The memory of a computer mayinclude any memory or database module. The memory may be volatile ornon-volatile types of non-transitory computer-readable media, such asmagnetic media, optical media, random access memory (RAM), read-onlymemory (ROM), removable media, or any other suitable local or remotememory component.

In the case of a plurality of computers, they are collectivelyconsidered as the cloud. The computers of the server are connectedthrough a communication network. The communication network may be aninternet, an intranet, a local area network (LAN), a wide area network(WAN) or a combination thereof.

The cloud is configured to host and process applications, includingstoring data associated with the environment. Such hosting andprocessing may be considered as cloud services provided by the cloud.Various types of cloud services may be provided. The cloud services maybe provided in a public, private or hybrid network. The cloud servicesmay be provided by a cloud service provider. For example, the cloudservices may be provided by SAP AG. Other types of clouds and cloudproviders may also be useful.

End-users may connect to the cloud using end-user devices. An end-userdevice may be a local computing device with, for example, a local memoryand a processor. The memory may be volatile or non-volatile types ofnon-transitory computer-readable media, such as magnetic media, opticalmedia, random access memory (RAM), read-only memory (ROM), removablemedia, or any other suitable local or remote memory component. Varioustypes of processing devices may serve as an end-user device. Forexample, the end-user device may be a PC, a tablet PC, a workstation, anetwork computer, a kiosk or a mobile computing device, such as alaptop, a tab or a smart phone. Other types of processing devices mayalso be used. End-user and end-user device may be used interchangeably.For example, when referring to an end-user, it is understood that theend-user connects to the cloud using an end-user device.

Connection to the cloud may be through the internet. The interconnectconnection may be using a mobile telecommunication network, such as a 4Gnetwork. Other types of connections to the cloud may also be useful. Anend-user may access the cloud by having a cloud account. For example, anend-user may access cloud services by logging onto a user account.

In one implementation, the environment 100 includes a hybrid applicationdevelopment system 140. The hybrid application development system 140,in one implementation, is a software tool for efficiently andeffectively developing, updating, packaging and deploying Apps. Thedevelopment system 140 includes an enhanced app developer 150 running onthe cloud 110. The enhanced app developer 150 includes a developmentenvironment 152. The development environment facilitates in creating andupdating Apps. In one implementation, the development environment is anintegrated development environment (IDE) 152. The enhanced app developer150 also includes an automatic deployment generator (DG) 156. The DGfacilitates in packaging and deploying new and updated Apps. In oneimplementation, the DG is an integrated DG (IDG). The system 140 alsoincludes a multi-purpose hybrid container 160. The hybrid container runson an end-user device 130. The end-user device, as shown, is a mobiledevice, such as a smart phone. The end-user device may alternatively bea desktop device. It is understood that numerous end-user devices may becommunicating with the cloud. The hybrid container sets up the nativeenvironment of the end-user device for the App in which to run.

A developer end-user 120 may log on to the cloud 110, accessing the appdeveloper 150. It is understood there may be numerous developerend-users communicating with the cloud 110. Using the IDE running on thecloud, the developer develops an App. In one implementation, the IDE isa web-based IDE. The web-based IDE runs on a web browser. The web-basedIDE may be a wizard-based IDE. For example, the IDE includes wizards toguide the developer end-user in developing Apps. The IDE, for example,may be a SAP River RDE from SAP AG Other types of IDEs may also beuseful. The App may be a mobile or desktop App. Once the App isfinished, the IDG 156, in one implementation, is automatically invoked.When invoked, the IDG packages the App (e.g., source code of the App)and deploys the App package to the cloud. For example, the IDG 156deploys the App package to an App store or market on the cloud. Forexample, the IDG packages the App's web content together with allrequired runtime libraries, Javascript framework, style sheets, imagesas well as other resources and automatically deploys to the App store onthe cloud.

In one implementation, the environment 100 includes a deployment servicehosted on the cloud. The App package is forwarded by the IDG 156 to thedeployment service, which deploys it to the App store.

As discussed, the development system 140 also includes a multi-purposehybrid container 160. The multi-purpose hybrid container 160 is prebuiltfor different native environments. For example, the hybrid container 160may be built to run on various native platforms. Native platforms mayinclude mobile platforms, such as iOS, Android and windows mobile, anddesktop platforms, such as Windows and MacOSX. Other types of platformsmay also be useful. The hybrid container 160, for example, runs on anend-user device. The hybrid container may serve as an App manager,managing the lifecycle of an App. The hybrid container, for example, mayinclude a set of plugins to manage the application credentials, lifecycle, as well as other functions. In one implementation, the hybridcontainer may be a SAP Kapsel Hybrid Container from SAP AG. Other typesof hybrid containers may also be useful.

In one implementation, the App is packaged in the multi-purpose hybridcontainer 160. For example, a new App (version 1) at the App store iscontained in the multi-purpose hybrid container. When an end-userdownloads the App, the hybrid container is installed to set up the Appin the native environment. The hybrid container may be continuouslyupdated to newer version via the Application store or market. Forexample, whenever the hybrid container is updated, it is pushed to theend-user. The web application content is updated in the hybrid containerof the end-user. By continuously updating the hybrid container,developers do not need to setup, maintain and update their own nativedevelopment environment. This avoids the complicated and error proneprocess for native application development.

Once deployed, an end-user may log onto the cloud and download the Appcontained in the hybrid container from the App store. When the App isdownloaded, the setup hybrid container is installed and runs on theend-user's device, setting up the native environment for the App. Forexample, the App is configured to run in the hybrid container.

The IDE may also be used to update Apps. For example, when changes arecommitted by the developer, the IDG automatically deploys the update tothe cloud. From the cloud, the App's web content will be automaticallypushed to the hybrid containers running on native platforms of end-userswho have already downloaded the App. In one implementation, anapplication update plugin is provided in the hybrid container. Theapplication update plugin communicates with the deployment service onthe cloud to get the updated App automatically pushed to it. A logonmanager plugin is also provided in the hybrid container. The logonmanager plugin manages who is subscribed for updates. For example, whenthe App is activated, the logon manager passes current information ofthe App, such as version and end-user. The cloud service compares theinformation and determines if there are any updates. Updates are pushedto the App by the deployment service on the cloud.

FIG. 2 shows an implementation of an enhanced App developer 150 ingreater detail. As shown, the App developer includes an IDE 152 and anIDG 156. The IDE includes an App configuration module 262, an App buildmodule 264 and an App update module 266. As for the IDG, it includes anApp scanner module 272, an App dependencies module 274, a file systemconversion module 276 and a packaging module 278. Providing the IDE andIDG with other modules may also be useful.

As discussed, the IDE facilitates in developing new Apps and updatingexisting Apps while the IDG automatically deploys new Apps and updatesto the cloud. Updates are then automatically pushed to end-user devicesalready having the App which needs to be updated.

An App developer end-user may access the enhanced App developer 150 bylogging into the cloud. In one implementation, a deploymentconfiguration is performed. For example, the App developer end-user mayaccess the configuration module 262 in the IDE. The deploymentconfiguration includes the developer end-user providing informationrelated to cloud deployment configuration. Such information, forexample, may include cloud server name, account name, password, as wellas other deployment configuration information. For example, otherinformation may include the target platform and whether automatic updateis enabled or not. In one implementation, the App configuration moduleemploys a configuration dialog to facilitate deployment configuration ofApps. The configuration dialog may be activated by selecting it on amenu bar in the IDE. Other techniques to effect deployment configurationmay also be useful.

FIG. 3 shows an exemplary implementation of a deployment configurationdialog 300. As shown, the dialog is for the cloud server “Helium”. Thedialog includes configuration parameters and corresponding boxes 311,321 and 331 for the user to enter the configuration information 310, 320and 330. In one implementation, the configuration parameter includesdevelopment account, username and password. For example, a user mayaccess his workspace in the server Helium by logging on using the user'susername and associated password. Command buttons may be provided in thedialog. In one implementation, OK and Cancel command buttons 340 and 341are provided. When information is correctly entered, the user may selectthe OK command button. The cancel button may be selected to clear orremove the dialog.

When a developer end-user creates an App (e.g., version 1), the buildmodule 264 in the IDE is accessed. The build module, in oneimplementation, provides a project wizard for creating an App. Thewizard requests various information from the developer end-userregarding the project or App. For example, the wizard requests projectname, information regarding application domain, etc. The wizard providesavailable templates for the developer end-user to use. The templates,for example, provide format for viewing selected data. Also, the wizardenables the developer to define the type of App, such as mobile ordesktop. Other techniques for developing Apps may also be useful.Command buttons may be provided by the wizard. For example, a finishedcommand button may be provided. When selected, the App is finished. TheApp created using the wizard is translated to source code by the IDE,such as, for example, HTML5, JS and CSS3. Other types of source codesmay also be useful.

FIG. 4 shows an exemplary implementation of a project wizard 400. Asshown, the project wizard is a new project wizard for creating a newApp. The project wizard includes various sections. For example, asshown, the project wizard includes a basic project information section410, an available template section 420, a template customization section430 and a confirm section 440. Providing wizards with other sections orother configurations may also be useful.

In the basic project information section 410, project name andapplication domain fields 412 and 414 are included. The name of theproject is provided in the project name field. For example, as shown,the project name is “proj1”. As for the Application domain field, it maypertain to the domain for different lines of business, such as CRM, ERM,as well as others. As shown, all domains are selected. The availabletemplate section 420 includes a list 422. The list 422 is a list ofdifferent project templates which are available for selection. Atemplate may be selected by, for example, clicking on the project box426. In such case, the template is selected for a mobile-basedapplication. A project box 424 may be provided for desktop-basedapplication. The template customization section 430 includes a view namefield 432. The view name field indicates which view is the initial viewof the application. In the confirm section, a finish command button 442is provided. Selecting the finish button, for example by clicking on it,indicates that the project is completed. Including other fields orconfigurations of the various sections may also be useful.

After the App has been created, the user selects the finish commandbutton 442 on the wizard. This triggers the IDG to run to effectdeployment. The deployment process is transparent to the user and runsautomatically in the servers on the cloud.

In the case of updating an existing App, the update module 266 in theIDE is accessed. The update module includes a source control (SC)system. The SC system, for example, may be a Git system unit. Othertypes of SC systems may also be useful. The SC system includes aninterface, enabling the user to make updates to the App.

When updates are finished, the user commits the updates by selecting thecommit command button in the SC interface. For example, the user commitsthe updated code. This triggers the IDG to run to effect deployment.

FIG. 5 shows an exemplary implementation of a source control (SC)interface 500. As shown, the SC interface includes a project explorer510, an IDE main menu 515, an IDE tool bar 520, an IDE text editor 530,a Git tool bar 540, Git status windows 545, a Git commit descriptioninput box 550 and a Git commit button 555. Providing other components orconfigurations for the SC interface may also be useful. The variouscomponents are used to effect updating of the App.

In the case of a new App (e.g., version 1) or an updated App (e.g.,greater than version 1), the App scanner module 272 of the IDG scans theApp. The term App, in this instance, may refer to either a new App or anupdated App. For example, the scanner module 272 identifies design timefiles and removes them, resulting in a scanned App. Design time filesmay include files, such as project setting and user preference files.Other types of design time files may also be included for removal.

The App dependencies module 274 analyzes the scanned file to resolveapplication runtime dependencies as well as retrieving dependentlibraries. For example, redundant libraries are removed from thedependency list while conflicts in dependencies are resolved. Thisproduces a resolved dependency (RD) App.

The file system conversion module 276 analyzes the RD App. Theconversion module 276 converts the App's file system, which is managedby the IDE on the cloud, to files and folders suitable for packaging andnetwork transfer. For example, the App's file system is converted to becompatible to the deployment service on the cloud. This produces aconverted App.

The packaging module 278 packages the converted App. In one embodiment,the packaging module includes a compression unit, metadata generatorunit, packaging unit and deployment unit.

The compression unit compresses the converted App. Compressing theconverted App, in one implementation, includes compressing the files ofthe converted App into compressed App. File compression, for example,may include minifying JS and CSS codes, compressing large text filesinto small binary files, as well as other actions. File compression,including code minification, is described in, for example, U.S. patentapplication Ser. No. 14/032,184, titled, “Packaging and Deploying HybridApplications” filed on Sep. 19, 2013, and which is herein incorporatedby reference for all purposes.

The metadata generator unit generates a deployment metadata filecorresponding to the compressed App. For example, the metadata generatorunit analyzes the compressed App's dependencies to generate the metadatafile. The metadata file defines the backend services used by the App.

An exemplary deployment metadata file is provided below:

{

-   -   “name”: “PODemo”,    -   “version”: “0.0.1”,    -   “main”: “www/Application.js”,    -   “repository”: {        -   “type”: “git”,        -   “url”: “https://git.neo.ondemand.com/testsapdev/podemo”    -   },    -   “private”: true,    -   “author”: “SAP Singapore”,    -   “keywords”: [        -   “cordova”    -   ],    -   “dependencies”: { },    -   “devDependencies”: {        -   “temporary”: “0.0.5”,        -   “cordova”: “3.4.0-0.1.3”            -   “welcomeFile”: “index.html”,    -   “routes”: [        -   {            -   “path”: “/resources”,            -   “target”: {                -   “type”: “destination”,                -   “name”: “ui5dist”,                -   “preferLocal”: true            -   },            -   “description”: “SAPUI5 Dist layer resources”        -   },        -   {            -   “path”: “/sap/public/bc/ui5_ui5/resources”,            -   “target”: {                -   “type”: “application”,                -   “account”: “sapui5”,                -   “name”: “sapui5”,                -   “preferLocal”: true            -   },            -   “description”: “SAPUI5 HTML5 Application with path in                ABAP”        -   },        -   {            -   “path”: “/sap/ui5/1/resources”,            -   “target”: {                -   “type”: “application”,                -   “account”: “sapui5”,                -   “name”: “sapui5”,                -   “preferLocal”: true            -   },            -   “description”: “SAPUI5 HTML5 Application with path in                XS”        -   },        -   {            -   “path”: “/sap/bc/adt/filestore”,            -   “target”: {                -   “type”: “destination”,                -   “name”: “gm6_abap_edit_ui5”            -   },            -   “description”: “ADT REST Resource API Backend”        -   },        -   {            -   “path”: “/sap/bc/ui5_ui5”,            -   “target”: {                -   “type”: “destination”,                -   “name”: “gm6_abap_execute_ui5”            -   },            -   “description”: “Target Gateway system with UI5 apps”        -   },        -   {            -   “path”: “/sap/opu/odata”,            -   “target”: {                -   “type”: “destination”,                -   “name”: “gm6_abap_odata”            -   },            -   “description”: “GM6 ABAP OData”        -   }    -   ]

}

The packaging unit packages the compressed App and metadata file to forman App package for deployment. In the case of a new App, for example,version 1 of an App, the compressed App and metadata file is packaged ina hybrid container, forming the App package. For example, the Apppackage includes the compressed App file containing the source code ofthe new App and the metadata file in the hybrid container. The hybridcontainer, for example, may be a Kapsel Hybrid Container from SAP AG.For an updated App, for example, greater than version 1, no hybridcontainer is used. For example, the App package includes the compressedApp file and metadata file.

As discussed, the cloud includes a deployment service. The deploymentunit of the IDG, for example, deploys the App package to the deploymentservice on the cloud. The deployment service receives the App packagefrom the IDG. The deployment service exposes its service. For example,the IDG sends a post request to the deployment service. In oneimplementation, the deployment service exposes its service as a standardREST service. For example, the IDG sends a REST post request to thedeployment service.

Communication between IDG and deployment service on cloud, in oneimplementation, is purely metadata driven. As such, no script orprogramming language is required between the IDG and deployment service.This advantageously results in a simple and secure interface between thedeployment service and IDG.

In the case of a new App, the deployment service deploys the packagedApp, which includes the hybrid container, to a persistent repository onthe cloud. For example, the App package is deployed to an App store. Inthe case of an updated App, the deployment service deploys or pushes theApp package to hybrid containers of end-users who already have the App.

FIG. 6 shows an implementation of a simplified deployment process 600for a new App. As shown, the process commences by creating a new App atstep 610. In one implementation, the new App is created using the IDE ofthe enhanced App developer. The App may be created using a projectwizard in the IDE. Creating an App using other types of IDE may also beuseful.

After the App is completed, the IDG is automatically invoked to processthe App at step 620. The IDG, in one implementation, processes the Appby scanning it to remove design time files. This, for example, producesa scanned App file. The scanned App file is scanned to resolve runtimedependencies as well as retrieving dependent libraries. This produces aresolved dependency (RD) App file. The RD App's file system is convertedto files and folders suitable for packaging and network transfer. Ametadata file is also generated, defining the backend services used bythe App. After that, the IDG packages the App and metadata file in ahybrid container for deployment. The packaged App, in this case,includes the App, metadata file and hybrid container.

The IDG, at step 630, deploys the packaged App to the deployment serviceon the cloud. The deployment service deploys the packaged App to the Appstore at step 640. An end-user may download the App to the hybridcontainer in the device.

FIG. 7 shows an implementation of a simplified deployment process 700for an updated App. As shown, the process commences by updating anexisting App at step 710. In one implementation, the App is updatedusing the IDE of the enhanced App builder. The App may be updated usinga SC system's interface. The SC system may be a Git system. Updating anApp using other types of SC systems may also be useful.

After updating is completed, the IDG is automatically invoked to processthe updated App at step 720. The IDG, in one implementation, processesthe App by scanning it to remove design time files. This, for example,produces a scanned App file. The scanned App file is scanned to resolveruntime dependencies as well as retrieving dependent libraries. Thisproduces a resolved dependency (RD) App file. The RD App's file systemis converted to files and folders suitable for packaging and networktransfer. A metadata file is also generated, defining the backendservices used by the App. After that, the IDG packages the App andmetadata file for deployment. For example, the packaged App, includesthe App and metadata file.

The IDG, at step 730, deploys the packaged App to the deployment serviceon the cloud. At step 740, the deployment service pushes the packagedApp of the updated App to hybrid containers of user devices which havenon-updated version of the App.

The enhanced App developer running on the cloud, as described,simplifies the App deployment workflow. For example, a new App iscreated in the IDE of the App builder using, for example, a projectwizard. Once the source code is committed, the IDG packages the App andmetadata file in a hybrid container and automatically deploys thepackaged App to, for example, an App store via a deployment service onthe cloud. An end-user can easily download the App package and installand setup a hybrid container in the App package to run on the end-userdevice. The App is installed and runs in the hybrid container on theend-user device. In the case of an update, once the source code iscommitted, it is automatically deployed to the deployment service on thecloud which then pushes the update to the hybrid container on theend-user device.

Since the App developer with the IDE and IDG and deployment service areall on the cloud, a developer end-user just need a browser to access theApp developer for deployment while an end-user needs a hybrid containerrunning on an end-user device. For example, an end-user just needs ahybrid container to receive the deployment and updates.

As described, the application development system may be embodied as anapplication. For example, the application development system may beembodied as a software application. The different components of thesystem may be separate software applications configured to operate orinteract with each other, whether on the cloud or on the end-userdevices. The source code of the applications may be compiled to createan executable code. The codes, for example, may be stored in a storagemedium, such as one or more storage disks or in memory of a serverand/or end-user devices. Other types of storage media may also beuseful.

Although the one or more above-described implementations have beendescribed in language specific to structural features and/ormethodological steps, it is to be understood that other implementationsmay be practiced without the specific features or steps described.Rather, the specific features and steps are disclosed as preferred formsof one or more implementations.

The invention claimed is:
 1. A computer-implemented method of packagingand deploying a hybrid application, comprising: in response to a userevent, providing a source code of the hybrid application by adevelopment environment running on a cloud server; and automaticallyinvoking a deployment generator to receive the source code of the hybridapplication by a deployment generator running on the cloud server,wherein the deployment generator comprises performing, scanning thesource code of the hybrid application to identify and remove design timefiles, resulting in a scanned application file, analyzing the scannedapplication file to resolve runtime dependencies of the hybridapplication as well as retrieving dependent libraries, resulting in aresolved application file, converting the resolved application file tofiles and folders compatible for deployment to a deployment service onthe cloud server, resulting in a converted application file, compressingthe converted application file to form a compressed application file,generating a deployment metadata file, packaging the compressedapplication file and the deployment metadata file to produce anapplication package, and deploying the application package to adeployment service on the cloud server.
 2. The method of claim 1wherein: the hybrid application comprises a new hybrid application; theapplication package comprises the compressed application file and thedeployment metadata file packaged in a hybrid container; and thedeployment service on the cloud server deploys the application packageto an application store.
 3. The method of claim 1 wherein: the hybridapplication comprises an update hybrid application; the applicationpackage comprises the compressed application file and the deploymentmetadata file; and the deployment service on the cloud server deploysthe application package to a hybrid container running on an end-userdevice.
 4. A computer-implemented method of packaging and deploying ahybrid application, comprising: in response to a user event, providing asource code of the hybrid application by a development environmentrunning on a cloud server; and automatically invoking a deploymentgenerator to receive the source code of the hybrid application by adeployment generator running on the cloud server, wherein the deploymentgenerator comprises performing, scanning the source code of the hybridapplication to identify and remove design time files, resulting in ascanned application file, resolving runtime dependencies as well asretrieving dependent libraries of the scanned application file whichresults in a resolved application file, converting the resolvedapplication file to files and folders compatible for deployment to adeployment service on the cloud server, resulting in a convertedapplication file, compressing the converted application file to form acompressed application file, generating a deployment metadata file,packaging the compressed application file and the deployment metadatafile in a hybrid container to form a hybrid application package, anddeploying the hybrid application package to the deployment service onthe cloud server.
 5. The method of claim 4 comprising configuring thehybrid application for deployment.
 6. The method of claim 5 wherein theuser event comprises: a developer logging into the cloud server; andcreating the hybrid application by the developer using the developmentenvironment running on the cloud server, wherein the source code of thehybrid application is automatically passed to the deployment generatoron the cloud server by the development environment when the hybridapplication is completed.
 7. The method of claim 6 wherein packagingcomprises: packaging the source code of the hybrid application in thehybrid container to form the hybrid application package, the hybridcontainer runs on different native platforms; and wherein the deploymentservice on the cloud server deploys the hybrid application package to anapplication store.
 8. The method of claim 6 wherein packaging comprises:compressing the source code of the hybrid application; generating ametadata file of the compressed source code of the hybrid application;packaging the compressed source code of the hybrid application and themetadata file in the hybrid container to form a new application package,the hybrid container runs on different native platforms; and wherein thedeployment service on the cloud server deploys the new applicationpackage to an application store.
 9. The method of claim 4 wherein thedeployment service deploys the hybrid application package to anapplication store.
 10. The method of claim 9 comprising: installing thehybrid container on an end-user device by an end-user when the end-userdownloads the hybrid application package from the application store tothe end-user device; and the hybrid application runs in the hybridcontainer in the end-user device.
 11. The method of claim 10 wherein anupdate of the hybrid application is automatically pushed to the hybridcontainer running on the end-user device.
 12. The method of claim 4wherein the user event comprises: a user logging into the cloud server;updating the hybrid application by the user using the developmentenvironment running on the cloud server, automatically passing a sourcecode of a completed update of the hybrid application to the deploymentgenerator; packaging the source code of the completed update of thehybrid application to form an update application package by thedeployment generator; and deploying the update application package tothe deployment service on the cloud server.
 13. The method of claim 12wherein the cloud deployment service automatically pushes the updateapplication package to the hybrid container running on an end-userdevice for an earlier version of the update application.
 14. Anapplication development system comprising: a computer system having aprocessor and a non-transitory storage medium, the computer system isdisposed on a cloud network, the computer system having an applicationdeveloper, wherein the application developer comprises, a developmentenvironment, the development environment enables a developer to create anew hybrid application or update an existing hybrid application toproduce an update hybrid application, and a deployment generator forpackaging the new hybrid application or packaging the update hybridapplication, the deployment generator includes an application scannermodule for scanning a source code of the new or update hybridapplication to identify and remove design time files, resulting in ascanned new or update application file, an application dependenciesmodule for resolving runtime dependencies as well as retrievingdependent libraries of the new or update scanned application file whichresults in a resolved new or update application file, a file systemconversion module for converting the resolved new or update applicationfile to files and folders compatible for deployment to a deploymentservice on the cloud network, and a packaging module having acompression unit for compressing a source code of the new or updatehybrid application to form a compressed new or update application file,a metadata generator unit for generating a metadata file to define backend service used by the new or update hybrid application, a packagingunit for packaging the compressed new or update hybrid application fileand metadata file to produce an application package for deployment tothe deployment service on the cloud network, and a deployment unit fordeploying the application package to the deployment service on the cloudnetwork.
 15. The system of claim 14 further comprising a hybridcontainer running on an end-user device, the hybrid container sets up anative environment of an end-user device in which the new hybridapplication runs or the update hybrid application runs.
 16. The systemof claim 15 wherein: the development environment is an integrateddevelopment environment; the deployment generator is an integrateddeployment generator; and wherein the deployment generator isautomatically invoked when the new hybrid application is completed orwhen the update hybrid application is completed.
 17. The system of claim14 wherein: for the new hybrid application, the packaging unit packagesthe compressed new application file and metadata file in a hybridcontainer to produce the application package which is a new applicationpackage for deployment to the deployment service which deploys it to anapplication store; and for the update hybrid application, the packagingunit packages the compressed update application file and metadata fileto produce the application package which is an update applicationpackage for deployment to the deployment service which pushes the updateapplication package to the hybrid container running on the end-userdevice.